Mobility Unified Reporting System Administration and Management

 

This chapter provides information on administering and managing the MUR application.

This chapter describes the following topics:

•	Launching the MUR GUI

•	Administration

•	Operations and Management

•	Troubleshooting MUR

Important: Please note that the terminologies “starbi”, “inPilot” and “mur” used throughout this guide mean the same.

Launching the MUR GUI

It is recommended to use either Internet Explorer (v 7.0+) or Mozilla Firefox (v 3.0.10+) browser for launching the MUR interface.

Note that:

•	No additional plug-in is required.

•	The javascript is enabled by default on the intended browser.

•	Suggested screen resolution is 1024 x 768 and above.

To launch the MUR interface:

1.	In a Web browser, enter the following URL:

http://<MUR-server-hostname or IP address>:<apache port>

For example, http://10.4.5.2:8080

2.	Enter your user name and password, and then click Log In. The user name must be an alpha and/or numeric string of 3 through 16 characters in length. The only special character that a user name can include is underscore (_).

Important: At first log on, the users are expected to enter admin as the input for the Username and Password fields.

The password must meet the following criteria:

•	Must be a minimum of 8 characters long and a maximum of 32 characters long

•	Must not be a repeat or reverse of the associated user name

•	Must not be more than 3 of the same characters used consecutively

•	Must contain at least 3 of the following combinations:

•	English upper case characters (A through Z)

•	English lower case characters (a through z)

•	Numerical (0 through 9)

•	Special characters (such as _, ., !, @, $, *, =, -, ?, etc)

The only account created after the initial set-up is admin / admin and it has Administrator privileges.

Once logged-in, the user’s Dashboard will be displayed with reports if already configured (the displayed reports are specific to each user account).

Important: At first log on, the users will see an empty Dashboard. The necessary data should be populated and required parameters should be configured for report generation.

The user name is always displayed on the right-up corner of the page until the user logs out of the application.

Administration

This section provides information on how to administer and manage the MUR application.

Managing User Accounts

The MUR application provides two levels of access privileges:

•	Administrator: Users in this group have the following privileges:

•	Create, edit, and delete other user accounts

•	Edit configuration settings

•	Activate, deactivate, and reset password for operator users

•	Generate and view reports

•	Operator: Users in this group can:

•	Generate reports

•	View module-level reports available to them

Important: Only administrator with admin name can create user accounts.

Please note the following limitations with respect to user permissions and privileges:

•	All MUR administrators have access to USERS and GROUPS menu in the Admin tab available on the MUR GUI.

•	Administrator with admin user name will have the rights to modify and delete all the MUR users’ accounts. Only users with admin user name can modify its own password. Only admin user will be able to delete any administrator or operator user accounts.

•	Administrator other than users with admin user name will have rights to delete the MUR users except admin user and modify user accounts except their passwords.

•	After modifying user role from Administrator to Operator and vice-versa, the user should alter the configuration on the GUI to lock/unlock the user account accordingly.

For more details, see the Cisco Mobility Unified Reporting System Online Help documentation.

Managing Gateways

The MUR application supports configuring multiple gateways for which reports can be customized and generated. Gateways are the chassis from which EDR and bulkstat files are fetched to the reporting server.

Important: Users with administrative privilege can only add and manage gateways.

When a gateway is added through the GUI, a directory by the name of the gateway is created in the <mur_install_dir>/starbi/server/data directory.

The gateway directory structure looks like the following:

<data directory>

|

|--> <Gateway name>

|

|--> edr

The MUR application expects the EDR files in the directories that are created when adding the gateway.

The MUR application supports the distributed model to allow the deployment which enables network wide view or work load balancing. Newly introduced component, Remote Data Processor (RDP), plays the role of pre-processing the input files from gateways. One or more RDPs, installed separately on remote machines can be registered to a master MUR system and one RDP can process files from one or more gateways. The role of MUR system in such deployments is mostly for report generation, report viewing, RDP management and optionally data processing.

The RDP parses the raw data or EDR files from GGSNs and periodically forwards it to the registered master MUR application through SFTP for report generation. For information on how to configure the RDPs, see the Mobility Unified Reporting System Online Help documentation.

Important: The gateways can be added on Remote Data Processor (RDP). For adding gateway on particular RDP corresponding RDP's region should be selected. RDP region is available when RDP is added. For information on configuring the RDPs, see Mobility Unified Reporting System Online Help documentation.

In 12.0 and earlier releases, each of the registered RDPs were considered to be a new region. RDP region can be a child of the root of the MUR system (NOC) or can be the child of another region. However, all the gateways associated with a RDP will always be the children of RDP region.

Whenever an RDP is configured, internally MUR used to create corresponding region for the same. However, with the introduction of scalable MUR in 12.2 release, one gateway's files will be processed by two or multiple RDPs. In that case, RDP does not stand as a region. Hence, the reports would be required across all the RDPs under one particular region.

Important: Whenever an MUR is upgraded from an older version to 12.2, the logical regions for the MUR gets void and the user will not be able to see any gateways under the DPI/Bulkstats/CF/KPI tab. In this scenario, the user should add that gateway under NOC.

Managing Archive Directory

To use the Offline Subscriber Search feature seamlessly, you must organize the archive directory date-wise. For information on this feature, see the Mobility Unified Reporting Online Help documentation.

MUR organizes the archive directory such that the directory structure looks like the following:

<Archive Directory>

  <Gateway Name>

     <Reporting Name>

        <Date YYYYMMDD>

           <Archived Files>

              <Other>

           <Archived Files>

For the files that are not satisfying the required EDR file name format, MUR stores the files in the Other directory.

Configuring Logging

The MUR application facilitates logging to trace and debug problems identified within the reporting system.

Important: Users with administrative privilege can only manage logging.

Configuring Purging Feature

The MUR application supports purging any kind of aggregated data like half-hourly, daily, weekly, monthly, etc. This also supports purging of weekly summary table, monthly top N table, audit logs, etc. While configuring the purging feature, the MUR provides the flexibility to end-user to configure half-hourly, daily, weekly and monthly report viewing duration so that the historical reports can be viewed even at a lowest granularity level.

Important: It is recommended that you enable backup feature and take one complete successful snapshot of backup before enabling purging feature. If the backup feature is disabled then enabling purging will cause removal of data without waiting for it to be backed up.

Important: The backup snapshot can be identified as complete only if the snapshot directory of format snapshot_<date>_<time stamp>_<version>, created under configured backup path does not have the prefix backup.prog. The backup.prog prefix indicates that the backup is in progress.

MUR uses a python script, purge_db.py, to accomplish this task. For more information on the script, refer to the Using the Purging Script section.

Important: Users with administrative privileges can only manage the purging configuration.

Important: The purging configurations are recommended to be a one-time process and should not be changed frequently.

To configure data / file purging through the GUI, see the Mobility Unified Reporting System Online Help documentation.

Important: In case of distributed model of MUR, data purging can be done only at the master MUR and file purging can be performed at per RDP level.

Important: For the MUR software with version 10.0.72 and lesser, you must manually purge the archived files. For the MUR software version 10.0.72 and later, you can use the purging script to automate the process.

Configuring Backup Functionality

To avoid data loss due to hardware failure and/or software crash, MUR supports periodical backup and recovery of its database. The backup is actually the snapshot of data tables or meta data on the day when the backup is taken.

In case of hierarchical deployment, when backup feature is enabled, backup of RDP is also taken as per user configured period.

Backup of RDP contains only the metadata i.e. the configuration information and does not consume high disk space. Also this backup snapshot which is taken on RDP node is immediately transferred to Master MUR using SFTP.

The Master MUR moves the snapshot of RDP backup to the backup path configured on RDP. In short, RDP backup snapshot is also stored on user configured backup path.

Important: Please note that the backup and recovery processes are applicable only for MUR database and not for files that are archived.

Please consider the following points while taking backup of the master MUR database.

•	Backup related configuration is available under ADMIN tab in Web-based MUR GUI.

•	Configure the backup path on a separate disk than using the path where MUR is installed. This can be NFS or any other storage path. The File system on storage disk should support creating hard links to the files for performance benefits. For example: UFS, ZFS and NFS.

•

MUR takes the snapshot as per the configured period. If the previous snapshot is available on backup path, data which was not modified between last backup and the current backup is copied directly from the previous snapshot. Thus it is recommended that the backup disk path should hold at least the recent snapshot. The disk size for backup path should be selected accordingly. Older snapshots can be archived or deleted regularly.

•	If the backup flag is disabled, the purging of data will continue even if some data tables are pending for backup.

•	The backup snapshot can be identified as complete only if the snapshot directory of format snapshot_<date>_<time stamp>_<version>, created under configured backup path does not have the prefix backup.prog. The backup.prog prefix indicates that the backup is in progress.

•

If MUR is being upgraded from a version in which backup and purging features are not available, to a version in which backup and purging features are supported, then it is recommended that you enable backup feature and take one complete successful snapshot of backup before enabling purging feature. If the backup feature is disabled then enabling purging will cause removal of data without waiting for it to be backed up. If the backup is being taken for the first time after upgrade, then it may take considerable time for first backup.

Configuring Recovery Functionality

To recover the backed up data, use the snapshot recovery script that finds the latest available snapshot amongst all the snapshots under configured path. If you want to recover specific snapshot then move only that snapshot to some other path and provide this new path as a parameter to this script.

Important: In case of hierarchical deployment, recovery of master MUR and RDP should be done separately. After recovering and starting RDP, it will start serving the master to which it is attached.

Please note the following key points while recovering the database.

•	The recovery of backed up tables is possible only during a fresh installation of MUR software. The fresh installation version should be same as the version for which snapshot is backed up.

•

Fresh installation for recovery purpose should be installed on the same path where last backup is stored and also should have the same IP address and port configuration if the MUR is deployed in distributed mode. Make sure that the existing older installation is either removed or moved to a different directory because the metadata recovered from previously installed MUR will have all references as per older installation e.g. archive path, SFTP details, etc.

•	The recovered data contains all the configurations as per older setup. Thus, any changes in the configuration of recovered setup, such as backup interval, etc requires reconfiguration explicitly.

The recovery script provides an option to specify if recovery of data is required for RDP.

For recovery of RDP, backed up snapshot should be copied on a local path or it should be available on path that is accessible to RDP.

For the master MUR, use the following command to recover the data:

./recover.sh -path <directory path containing data snapshots>

For RDP, use the following command to recover the data:

./recover.sh -path <directory path containing data snapshots> -r <RDP_Name>

The option -r <RDP_Name> denotes the name of RDP for which data should be recovered.

The snapshot of RDP is a tar file and not a directory as in the case of master MUR. The following is a sample of RDP backup tar file naming convention.

RDP_<RDP_Name>_snapshot_<Date>_<timestamp>_<version>.tar

Configuring Offline Mode

MUR can be used in “Offline Subscriber Search Only” mode. In this mode, MUR will not parse incoming EDR files, so no online reports will be generated. It will move the incoming EDR files to archive directory, so that you can avail “Offline Subscriber Search Reports” only. By default, this mode is turned OFF. To run MUR in Offline Mode, please see the configuration parameters OFFLINE_MODE and OFFLINE_SEARCH_PROCESS_COUNT in Managing System Configurations > Config Parameters in the Mobility Unified Reporting System Online Help documentation.

Operations and Management

This section provides information on the scripts that can be used to manage the MUR components and the reports.

 

Using the Maintenance Utility

A shell script utility called serv is included with MUR in the <MUR_install_dir>/starbi/bin directory.

This serv script can be used to manage the following MUR processes:

•	Process Monitor (PSMON) Application

•	Scheduling Server

•	Postgres Server

•	Apache Server

•	Notif Server

•	Parser Server

•	Cache Server

This utility can report the status of the MUR processes on the system or it can be used to stop the MUR process.

Following are the options available with the serv script:

./serv { psmonitor | scheduler | postgres | apache | notif_server | parser | cache_server } [ start | stop | status ]

Keyword	Description
psmonitor	This is an optional keyword used with the serv script. This represents the PSMON application. It starts/stops/checks the following MUR processes. • Postgres server • Apache server • Scheduling server • Notif server • Parser server • Cache server
scheduler	This is an optional keyword representing the scheduling server.
postgres	This is an optional keyword representing the postgres server.
apache	This is an optional keyword representing the apache server.
notif_server	This is an optional keyword representing the notif server.
parser	This is an optional keyword representing the parser server.
cache	This is an optional keyword representing the cache server.
start	Starts each MUR process.
stop	Kills or stops the running MUR process.
status	Displays the status of each MUR process. By default, it will show the status of all the MUR processes.

‌

For example, if you want to start only the PSMON, then enter the following command:

./serv start psmonitor

or

./serv psmonitor start

Important: If you stop the MUR process, make sure that PSMON is not running. Otherwise PSMON will restart the MUR application.

The following is a sample output of the serv status command:

---------------------------------------------------

--------------- MUR Process Status ------------

 PID            Process                  Status

---------------------------------------------------

4245          Process Monitor           Running

4256          Scheduling server        Running

4267          Postgres Server         Running

4289          Apache Server           Running

3249          Notif Server           Running

3243          Parser Server           Running

2430          Cache Server           Running

---------------------------------------------------

Using the PSMON Script

PSMON is a perl script that is used to monitor the Scheduling Server, Postgres Server, and Apache Server processes. This script can start or stop the processes based on certain thresholds specified in the MUR configuration file. The PSMON respawns any dead processes using the set of rules defined in the configuration file.

This script can also optionally send notifications to users via e-mail.

Generating Reports in Excel Format

To generate the reports in excel format, execute the following script from the <MUR_install_dir>/starbi/bin directory.

./get_excel_report.sh -day <date for report generation> -f <path where report should be stored> -filter <filter for the report>

The script takes three parameters, the date for which report is to be generated, the path where generated report is to be stored, and the filter for the reports. The date must be in mm-dd-yyyy format only, and the filter can be based on Type Allocation Code (TAC) or Access Point Name (APN).

Using the unanonymize_msisdn.sh Script

MUR reports the subscribers data like Mobile Station Integrated Network (MSISDN) in the encrypted format both in the GUI and Excel file. Decryption functionality is ONLY supported on CLI through the use of unanonymize_msisdn.sh script.

This shell script utility will check for user’s privilege before decrypting the MSISDNs. It will prompt for the GUI administrator password.

Usage of unanonymize_msisdn.sh Script:

Important: Please note that this script must be run ONLY in bash shell.

./unanonymize_msisdn.sh -u <username> -f <input file> -d <output path>

Option	Meaning
-u	Used to specify GUI Administrator user name.
-f	Used to specify the absolute input file path of a file containing list of anonymized MSISDNs. Each anonymized MSISDN will be separated by a new line.
-d	Used to specify the output directory path where the decrypted MSISDNs file will be stored.
-h, --help	Prints this help.

‌

To decrypt the MSISDN(s), perform the following steps:

1.	Get an excel report for the day for which you want to see the clear text top subscribers or MSISDN(s). For information on how to get the excel report, refer to the Generating Reports in Excel Format section in this chapter.

2.	Copy all lines from "Anonymized MSISDN" column of work sheet "Top 1000 Subscribers Traffic" and paste them in to a separate text file.

3.	Provide this text file as an input to the unanonymize_msisdn.sh script.

Important: Please note that the users require GUI administrator credentials to access this utility.

Resetting GUI Administrator User Password

In case the Administrator user forgets the password, a set_admin_password.py script is used to reset the password. This script is located at the <MUR_install_dir>/starbi/server/scripts directory.

To reset the Administrator user’s password, perform the following steps.

Step 1

Execute the following commands to set the environment variables.

#source server/env.properties

#export PYTHONPATH

#export LD_LIBRARY_PATH

Step 2

Execute the following script.

#python2.6.1/bin/python server/scripts/set_admin_password.py

The script will update MUR database with Administrator user password as admin.

Using the generate_dns_mapp_sql.sh Script

To generate the DNS mapping for the specified list of IP addresses, execute the following script from the <MUR_install_dir>/starbi/bin directory:

./generate_dns_mapp_sql.sh <input file for IP> <output file where mapping should be stored>

Keyword/Variable	Description
input file for IP	A file containing IP addresses. Each IP address must be present in a new line.
output file where mapping should be stored	An output file for storing the DNS mappings in SQL format.

‌

This script is used to perform Internet DNS lookup of the specified IP addresses. It uses the ‘nslookup’ system administration command to find the DNS name of the specified IP. Please note that the machine must be connected to Internet for successful execution.

Generating Unknown URL Files

For CF reporting, MUR should parse CF-EDRs and generate the unknown/unrated URL database. This database will be pulled periodically by WEM and subsequently deliver to Rulespace. The unknown URL files can either be time based or count based.

To generate the unknown URL files, execute the following script from the <MUR_install_dir>/server/scripts/cfedr directory:

./gen_unknown_url.py

Important: Please note that up to a maximum of 85,000 Unknown URLs can be present in each file.

Using the getSupportDetails Script

In the event additional troubleshooting assistance is required, debugging information can be collected using a script called getSupportDetails.pl. This script collects different log files and captures the output of certain system commands that aid in troubleshooting issues. This script is packaged with MUR in the <MUR_install_dir>/starbi/tools/supportdetails/ directory.

This script refers to an XML file to get the list of logs. This XML file resides in the same directory as the script. Once executed, the script retrieves the contents of logs, files, folders, and output of certain commands and prepares a zipped file (MURsupportDetails.tar.gz), by default it is placed in /tmp/log directory.

Requirements

Perl 5.8.5 and above is required for running the script.

Apart from standard Perl modules (which are included in default installation of Perl), some additional modules are required for running the script. The list is as follows:

•	expat version 1.95.8

•	XML::Parser version 2.34

•	XML-Parser-EasyTree

•	Devel-CoreStack version 1.3

These modules are installed by default by the product. Please ensure that the above mentioned modules are installed when using a different installation of Perl.

To run the script, change to the directory path where the script is present and type:

./getSupportDetails.pl [--level=...] [--xmlfile=...] [--help]

Keyword/Variable	Description
--level	Specifies the level of debug to run. It can have a maximum of 4 levels. The level 4 provides the most detailed information. Default: 1
--xmlfile	Specifies the xml file name to be used for collecting the log. Default: getSupportDetails.xml
--onlyrecentlogs	Collects only recent logs and skips detailed logs. Default: Collects detailed logs
--collectFor	Collects problem specific logs and information which is not collected under normal levels. This can be combined with --level option. Default: Collects logs covered under '--level' option.
--help	Displays the supported keywords/variables.

‌

For example, ./getSupportDetails.pl --level=4 --xmlfile=/tmp/getSupportDetails.xml

Supported Levels

The logs that can be collected for different levels are as follows:

•

Level 1:

•	Recent Log files

•	Current status (running / not running) of the product

•	Current Config files of the product

•

Level 2:

•	Logs from Level 1

•	Installation Logs

•	Database Logs (if available)

•	Web Server logs (if available)

•	Information of Solaris version and current patch installed

•	Output of the following commands:

netstat -an

ifconfig -a

df -k

etc..

•

Level 3:

•	Logs from level 2

•	Syslog Configuration and log files

•

Level 4:

•	Logs from level 3

•	All Log files (including old logs)

•	Crontab entries

•	Information of packages installed

•	Stack trace of any crash files (if debugger is installed on local machine)

•	System Libraries only if any core file present in crash directory

•	Level of Solaris installed

•	Output of the following commands:

ipcs

ps -eaf

etc..

Using the Purging Script

The python script, purge_db.py, handles both data purging and archived file purging. This script is packaged with MUR in the <MUR_install_dir>/starbi/server/scripts/utils/ directory.

This script runs daily at the end of the day, picks up the relevant tables, and then purges either data or archived files based on the configurations.

In case of data purging, the script picks up the relevant tables and purges them.

In case of file purging, the script purges the files only if the archived files are organized date-wise for each of the reportings like FLOW-EDR, HTTP-EDR, CF-EDR, and BS. For example, EDR file for 24th September, 2010 is stored in the archive/<gw>/flowedr/20100924 directory.

Server Script Parameters

The number of files being processed during each parsing interval for HTTP and non-HTTP EDRs can be controlled using the following parameters:

•	EDR_TOTAL_NO_OF_FILES = 25

•	EDR_MAX_NO_OF_PROCESSES = 5

•	HTTP_TOTAL_NO_OF_FILES = 25

•	HTTP_MAX_NO_OF_PROCESSES = 5

These parameters are defined in System menu under File parsing configs option available on the GUI.

With the above default configuration, if the number of files being accumulated are less than 25 and not in multiples of 5, then MUR spawns one more process to parse the remaining files.

Troubleshooting MUR

This section provides information on how to resolve situations you might encounter with using MUR software. This section provides problem definitions, their likely cause(s), and solutions.

Problem:	The EDR files are generated and moved out from the input directory. However, there are no reports getting generated.
Possible Cause(s):	The files may not be available in the archive directory i.e. <MUR_install_dir>/starbi/archive.
Action(s):	• Check if the files are available in the archive directory. • Check if they are marked invalid. If yes, check if there are any headers present in the files. If not, you need to configure ECS appropriately. • If the headers are present, check if all the required headers are present in the files.

‌

Problem:	MUR reporting client cannot be started.
Possible Cause(s):	The web browser cache might be full.
Action(s):	The browser cache must be cleared. In the case of Firefox, follow these steps: • On the Tools menu, click Clear Private Data. • Select Cache check box. • Click Clear Private Data Now. In the case of Internet Explorer, follow these steps: • On the Tools menu, click Internet Options. • Click Delete. • Select Temporary Internet files check box. • Click Delete. Important: The Firefox version supported for MUR is 3.0.10 and later. For Internet Explorer, it is 7.0 and later.

‌

Problem:	The bulkstats or KPI reports are not generated.
Possible Cause(s):	The bulkstats file might not be parsed.
Action(s):	• Check if the bulkstats schemas are properly configured on the gateway through the BULKSTATS menu in the ADMIN tab. • Check if the prerequisites described in the Configuring Bulkstats Schemas section of the Configuring Chassis for MUR chapter are met. • On the ADMIN menu, check the bulkstats audit under AUDIT. The audit should indicate whether the bulkstats files are being parsed or not. For more information, refer to the Cisco Mobility Unified Reporting System Online Help documentation. • Check if FTP is enabled on the MUR server. • Check if the bulkstats are FTPed to correct location on the MUR server from the gateway. The path should be as follows: $STARBI_HOME/server/data/$gwname/bs Where $STARBI_HOME = MUR installation directory, $gwname = Gateway name • Check if the Bulkstats/KPIs UI show only one day data • Check if the counters of same schemas are added in the formula while configuring KPIs. For example, if you are adding KPI in SGSN schema, then you should add counters of SGSN only in the formula. • Check if the bulkstat files are always pushed from gateway to master MUR and not to RDP.

‌

Problem:	Parser is not handling data files properly.
Possible Cause(s):	The file might be corrupted.
Action(s):	• File are marked as 'UNPROCESSED.<file>' and moved to archive directory if one of the following conditions are met: • file is '.gz' and corrupted with CRC error. • file is empty. • file does not have a header. • File are marked as 'CORRUPTED.<file>' and moved to archive directory if the file is '.gz' and corrupted (other than CRC error) like 'invalid compressed data--format violated'

‌

Problem:	Unable to add / edit / delete gateways.
Possible Cause(s):	The gateway configuration may be incorrect.
Action(s):	• Check if correct IP is provided while adding the gateway. • Check if gateway host is reachable from MUR. For more information, refer to the Cisco Mobility Unified Reporting System Online Help documentation.

‌

Problem:	Unable to add / edit / delete RDPs.
Possible Cause(s):	The RDP configuration may be incorrect.
Action(s):	• Check if correct IP and port are provided while adding RDP. • Check if RDP is actually running on remote machine. • Check if RDP host is reachable from MUR. For more information, refer to the Cisco Mobility Unified Reporting System Online Help documentation.

‌

Problem:	Duplicate reports are generated and/or the reports are incorrect.
Possible Cause(s):	MUR might have parsed half-cooked files.
Action(s):	The chassis tags the EDR files with a prefix ‘prog.’ while transferring to MUR. After the transfer is complete, the chassis removes the ‘prog.’ tag. The ‘prog.’ prefix indicates that the file is half cooked. • Check if the EDR files with the prefix ‘prog.’ are ignored. • Check if EDR file formats are configured properly.

‌

Problem:	The archived files are not getting purged even after configured purging interval.
Possible Cause(s):	MUR might have parsed half-cooked files.
Action(s):	• Check the ownership of files in the archive directory. They must be owned by MUR group user. • The entity pushing the files to MUR, for example, L-ESS should be added to MUR user group. For details, refer to the Managing Mobility Unified Reporting System Installation chapter of this guide.

‌

Problem:	If user is not able to configure bulkstats schema through Add Schema configuration screen that appears by selecting ADMIN > Bulkstats menu.
Possible Cause(s):	The initial prerequisites might not be met.
Action(s):	• Check if the prerequisites described in the Configuring Bulkstats Schemas Using GUI section of the Configuring Chassis for MUR chapter are met. • Check if the SSH Username in the Add Bulkstats schema configuration screen is specified correctly. This user name is used to connect to gateway via SSH for schema configuration. For information on how to configure the schemas, refer to the Configuring Bulkstats Schemas Using GUI section. Also, see the Cisco Mobility Unified Reporting System Online Help documentation.

‌

Problem:	The bulkstats files are not pushed from the chassis to the MUR server even after successfully configuring schemas.
Possible Cause(s):	The related configurations might be incorrect.
Action(s):	• Check if Username specified in the Add Bulkstats schema configuration screen is present in MUR group on the MUR server. To create the username if it does not exist on MUR server, use the following command: useradd <new user name> If the user is already present then use the following command to add the user in the MUR group. usermod -G <MUR Group> <user name> • Check if Destination specified in the Add Bulkstats schema configuration screen is correct or not.

‌

Problem:	While configuring bulkstat schema if configuration screen hangs for a long time.
Possible Cause(s):	The session might be timed out.
Action(s):	• Close the browser and try to configure the schema again. • Restart apache server by executing the following command from the <mur_install_dir>/starbi/bin directory and try again to configure the schema. ./serv start apache

‌

Problem:	If user is not able to edit the schema configuration through the Add Bulkstat schema configuration screen.
Possible Cause(s):	The schemas may not be configured properly.
Action(s):	• Follow the steps mentioned for above 3 cases. • If you are still not able to configure then delete the schema configuration for that particular schema from the GUI and try to configure again.

‌

Problem:	./serv status shows Postgres processes as NOT RUNNING
Possible Cause(s):	The shared memory configuration in the /etc/system directory might not be correct.
Action(s):	• Check if "shmmax" has been appropriately configured in the /etc/system directory (for Solaris users) or /etc/sysctl.conf directory (for Linux users). It should be set to 2684354560 (2.5GB). Reboot the system after making the changes to this file. • Check the available disk space (especially swap or /tmp) using df -hk command. • Try stopping other MUR instances on the machine. Each MUR instance will consume 2.5 GB of system’s shared memory. Use the prstat --a command to check the used and free memory.

‌

Problem:	If sftpying of EDR/UDR files failed
Possible Cause(s):	• SSH keys and SFTP server might not be configured appropriately. • SFTP might not be running on MUR server.
Action(s):	SSH keys and SFTP server need to be configured on the chassis and also SFTP should be running on MUR server. • Check if the following variables in the sshd_config file present in the /etc/ssh directory are set appropriately. • PermitRootLogin = yes • PasswordAuthentication = yes • PAMAuthenticationViaKBDInt = no (Applicable ONLY for SOLARIS) • UsePAM = no (Applicable ONLY for RHEL) • Comment the line “PAMAuthenticationViaKBDInt yes” as “#PAMAuthenticationViaKBDInt yes” • Update the SFTP parameters as necessary if the variables are not set properly. • After updating restart SSH daemon using the following commands: For Solaris 9: /etc/init.d/ssh restart For Solaris 10: svcadm restart svc:/network/ssh:default For RHEL: service sshd restart If the problem still persists, remove the EDR generation configuration from the gateway and reconfigure them.

‌

Problem:	If the EDR files are not getting parsed on the RDP and the files still remain in the input directory
Possible Cause(s):	The EDR configuration might be incorrect.
Action(s):	• Click ADMIN tab from the MUR GUI. • Click Edit for the gateway for which the EDR files are not getting parsed. • Check the values for the “Flow-Edr Filename Path” and “Http-Edr Filename Path” parameters and compare them with the actual path of files on RDP.

‌

Problem:

While adding RDP, if the MUR GUI throws the following error message “Could not communicate with RDP”

Action(s):

• Check if the Apache server of RDP is running. • If it is not running, start the server using serv start command. • If it is running, check if the Firewall is running on RDP. To check the Firewall status, use the following command: service iptables status • If the output indicates “No firewalls running”, check the Firewall settings for the associated ports and also check if the ports configured for RDP are in use. • From the command output, if you find the Firewall to be running, stop it with the service iptables stop command and then retry. • If you receive this message “RDP is already configured”, please contact Cisco Advanced Service Team for additional support and guidance.

‌

Problem:

Though the EDR files are parsed at the RDP, the reports are not available for a gateway attached to the RDP

Action(s):

• Check if RDP is actually running on remote machine. • Check if there are any pending files in the RDP's /starbi/server/sql_export_data/ directory. • If there are any pending files, check if the following log is shown in the starbi_server_devel file located in the /starbi/logs/server/ directory. Unable to open host keys file" [rdptomaster_file_mover.py ... ]" • If the logs are found, perform the following procedure: • Log on to the RDP machine. Switch the user as RDP admin. If you have set RDP admin as myrdp during RDP installation, then execute the following command su - myrdp. • Create an SFTP session to master (sftp masteradmin@masterhost) The output will look something similar to the following: Connecting to <masterhost>... The authenticity of host <masterhost> (<master ip address)' can't be established. RSA key fingerprint is <some key>. Are you sure you want to continue connecting (yes/no)? • Enter yes and quit the SFTP session. • Check the files again in the starbi/server/sql_export_data directory to identify if they are present now. Then, check the reports after a while. • If the reports are still not seen, check the master configuration in System menu. Check if the master login and password are specified. Ensure that master admin password has been set using password command on the master. If the solution provided above does not help to resolve your problem, please contact Cisco Advanced Service Team for additional support and guidance.

‌

Problem:	./serv status shows cache server is not running.
Possible Cause(s):	The port used by cache server implicitly is postgres port + 2. This is not a configurable port. Make sure that this port is not occupied by any other process.
Action(s):	• Free the required port for cache server. • Reinstall MUR with postgres port such that postgres port + 2 will be free and can be used by cache server.

‌

 

 

 

Cisco Systems Inc.

Tel: 408-526-4000

Fax: 408-527-0883